Subject: An architectural framework?

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Wed, 18 Aug 93 17:11:10 EDT

The problem I've been having with discussions on several of the siglets
is that connections between DLSW nodes for network control purposes (e.g.
CANUREACH, ICANREACH) are assumed to be the SAME connections on which
data is routed.

Here's a simple architectural framework that has helped me sort out some
of this complexity.  I see the DLSW as having 3 functional components:

(1) An access piece.  How the DLSW interacts with specific datalinks and
    non-routable LAN protocols.  The semantics of which frames should be
    handled as address resolution protocols, flow control protocols,
    circuit establishment/takedown triggers, or just plain data to send.
    How the DLSW keeps track of addressable network-layer entities on
    attached LANs.  How multiple DLSWs on the same LAN coordinate which
    one will perform specific functions on behalf of a network-layer
    entity.  Some people call this ES-IS.

(2) A network control piece.  Establishment of transport connections
    between appropriate DLSWs to be used for exchange of control
    information.  Current control information is limited to things like
    CANUREACH, ICANREACH (I consider this an address resolution protocol
    not too dissimilar to APPN's).  Additional control functions could
    potentially be implemented, depending on the amount of dynamics
    customers require.  Some people call this IS-IS.

(3) A data transport piece.  Currently, data flows on TCP/IP transport
    connections, the same DLSW TCs that are used for network control,
    but this would not necessarily have to be the case in the future.
    One of the siglets was having some discussions about bringing up and
    taking down TCs dyamically as needed.

Using this framework it seems that loop prevention (a la 802 spanning
tree) doesn't necessarily contradict having a mesh of control connections
between the switches.  Having a mesh is an entirely separate issue
(probably undesirable from a scalability standpoint, however).

I mentioned this over lunch at SHARE with Richard Livingston, Anson Chen
and Al Schwartz from Cisco, and they seemed to think this paradigm made
sense and makes this problem easier to think about.  What do you think?
Is this framework helpful?

Marcia Peters - Networking Systems Architecture - IBM

---

From: [email-masked] (John R. Pickens)
Date: Wed, 8 Sep 93 7:54:23 PDT

Marcia,

Sorry for delayed response to your proposal - have been traveling.  I like the
architectural framework proposal.  Would also suggest that as we exit this
stage of the 7 little siglets, that we use the architecture framework to
structure the group into 3 big siglets.

JP

--